1. Field of Invention
The present invention relates generally to enterprise environments. More particularly, the present invention relates to substantially optimizing the efficiency of local transactions and connection sharing, both individually and in combination, within an enterprise environment.
2. Description of the Related Art
The Java 2 Platform, Enterprise Edition (J2EE) is an industry-standard general purpose platform for the development of enterprise business applications. The enterprise business applications developed for J2EE include transaction processing applications, such as purchase order management, for processing transactions on Internet servers. The application logic of these applications is typically implemented as components, particularly as Enterprise JavaBeans (EJB) components. EJB is the application component model of the J2EE platform. One of the key advantages of the BIB component model is that it is relatively easy for application developers to design and implement EJB applications. In addition, as the EJB is a popular industry standard, there are a number of already existing powerful application development tools that further simplify the development of EJB applications.
In general, an EJB component model is a component architecture for the development and the deployment of object-oriented, distributed, enterprise-level applications. An application developed using the BIB component model is scalable and transactional, and is typically portable across multiple platforms, which enables an EJB component to effectively be “written once” and “used substantially anywhere.” That is, EJB components may also be used by multiple applications, i.e., EJB components may be shared or reused. As will be understood by those skilled in the art, the EJB component model enables application development to be simplified due, at least in part, to the fact that typically difficult programming problems are implemented by an EJB container, and not the application.
Typically, transactions within an enterprise environment are either global or local. For a global transaction, more than a single resource manager is used during the transaction. Alternatively, for a local transaction, only a single resource manager is used during a transaction. A resource manager, as will be appreciated by those skilled in the art, is a module that effectively manages a set or resources or data. Hence, the resource manager may be associated with databases, file systems, and substantially any suitable enterprise environment resources.
With reference to FIG. 1, one conventional method for performing transactions in an enterprise environment, e.g., J2EE, will be described. At the beginning of a transaction process 102, when an J2EE application needs access to a J2EE component such as an EJB, the J2EE application may provide a deployment hint to the container, i.e., the J2EE container, associated with the component in step 104. Once a deployment hint, if any, is provided, the component tells the container to start a transaction in step 108.
A determination is made in step 112 as to whether a hint was provided. In other words, it is determined whether the J2EE application provided a deployment hint to the container. If it is determined that a hint was provided, then process flow moves to step 114 in which it is determined whether the provided hint was a local hint, i.e., whether the hint indicates that the transaction is a local transaction. As previously discussed, a local transaction is generally a transaction during which a component interacts with only a single resource manager. Further, during a local transaction, the component generally may not access other components which are not included in the same container as the component.
When it is determined in step 114 that a local hint was provided, the container initiates a local transaction in step 116. During the course of the local transaction, the component accesses a single resource manager in step 118. At some point after the single resource manager is accessed, in step 120, the component effectively tells the container to complete the local transaction. Typically, the container is told to complete the transaction using the local transaction mechanism of the transaction manager. Once the component tells the container to complete the local transaction, the container uses the local transaction mechanism of the resource manager to complete the local transaction in step 122, and the process of performing a transaction is completed.
Returning to steps 112 and 114, if it is determined either that a hint was not provided or that a provided hint was not local, respectively, then the indication is that the transaction is a global. In general, a default assumption in a J2EE environment is that transactions are typically global. When it is determined that a transaction is global in either step 112 or 114, process flow moves from either step 112 or 114 to step 124 in which the container initiates a global transaction. During a global transaction, multiple resource managers are typically accessed in step 126.
After a set of resource managers are accessed, the component may request that the container complete the global transaction in step 128. Accordingly, the container uses its transaction coordinator to complete the global transaction in step 130, and the process of performing a global transaction is completed.
It has been observed that the majority, e.g., approximately 95 percent, of transactions in a J2EE environment are local. Hence, having the container start a global transaction by default if a deployment hint is not provided often wastes computational resources which could otherwise be allocated for other uses. Specifically, starting local transactions uses less overhead than starting global transactions. As a result, having a container start a global transaction when a transaction is more likely than not to be a local transaction often wastes computational resources, due at least in part the fact that the transaction that is started is likely to be a local transaction, and not a global transaction. Processing a local transaction as a global transaction is also typically inefficient.
In order to enable transactions to take place, connections between J2EE components and resource managers must be made or otherwise provided. Such connections may either be shared or distinct. FIG. 2 is a process flow diagram which illustrates the steps associated with a conventional method of providing connections. A process 202 of sharing connections begins at step 204 in which a J2EE application provides a deployment hint, if any, to a container. Typically, the hint provided in the context of connection sharing is the same hint provided with regards to a local transaction. In step 208, a J2EE component accessed by the J2EE application, and contained within the container, requests a first connection, i.e., a connection to a resource manager. The request is made through the container to which any existing or suitable deployment hint was provided. In response to the request for a connection, the container provides a distinct connection to the resource manager in step 212. A subsequent connection is requested by the J2EE component in step 216.
Once a request is made for a subsequent connection, a determination is made in step 216 as to whether a deployment hint was provided to the container. If it is determined that a deployment hint was provided to the container, then a determination is made in step 224 regarding whether the provided hint was a local hint. That is, it is determined if the hint indicates that the new connection is local with respect to the first connection, i.e., that the new connection is to the same resource manager as the first connection. If it is determined that the provided hint was a local hint, the container provides a shared connection by sharing an existing connection, e.g., the first connection, in step 226.
After the shared connection is provided, the J2EE component communicates with the resource manager over the shared connection. In some cases, the J2EE component may request another connection. Such a connection request may be a request for a connection to the same resource manager, or a request for a connection to a different resource manager. A determination is made in step 230 as to whether the J2EE component has requested a subsequent connection. When it is determined that the J2EE component has not requested a subsequent connection, the process of providing or implementing connections with respect to a particular J2EE component is completed.
Alternatively, if it is determined in step 230 that the J2EE component has requested a subsequent connection, the indication is that a determination should then be made regarding whether the requested subsequent connection should be a distinct connection or a shared connection. Accordingly, process flow returns from step 230 to step 220 where it is determined whether a hint was provided.
If the determination in step 220 is that no hint was provided, an assumption is typically made that a distinct subsequent connection is required. In other words, an assumption is made that a “default” connection is a distinct connection, or that unless a local hint is provided, a connection is not to be shared. As such, process flow moves from step 220 to step 234 in which the container provides a distinct subsequent connection. Once the distinct subsequent connection is provided, a determination is made in step 230 regarding whether the J2EE component requests yet another subsequent connection.
Returning to step 224 and the determination of whether a hint is a local hint, it should be appreciated that, often, if a hint is provided, a hint is a local hint. In such a case, a determination of whether a hint is a local hint may be eliminated. However, when a determination is made as to whether a hint is a local hint, if it is determined that a hint is not a local hint, then the implication is that the hint is such that the subsequent connection must be distinct. Therefore, process flow moves from step 224 to step 234 in which the container provides a distinct subsequent connection. After the connection is provided, a determination is made in step 230 as to whether the J2EE component requests another subsequent connection.
Connections are often shareable. However, unless a hint is provided by a J2EE application that informs a container that a connection may be shared, connections are maintained as distinct connection. Since hints are not always available, many connections which are sharable are effectively maintained as unshared connections. Not sharing connections which are sharable is generally inefficient, as the overhead associated with providing and maintaining the distinct connections is significant. Eliminating the overhead associated with providing and maintaining effectively unnecessary distinct connections by substantially always sharing connections which are sharable would increase the efficiency with which transactions which use the connections may be performed. Specifically, the overall performance associated with a J2EE application which uses the shared connections may be improved.
Therefore, what is desired is an efficient method and apparatus for performing local transactions and for sharing connections is desired. Specifically, what is needed is an efficient method and an apparatus for substantially preventing global transactions from being started when transactions are actually local and for enabling connections to be shared when connections are sharable.